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1 .   INTRODUCTION 

This  report  is  a  discussion  of  the  types  of  commands  which 
should  be  available  in  the  operating  WEB  System.   These  commands 
enable  a  designer  to  simply  and  quickly  make  modifications  to  a 
particular  design.   Provided  with  these  tools,  the  designer  can 
readily  compare  different  designs,  and  on  this  basis  select  a  pro- 
duction design. 

It  is  assumed  that  the  designer  will  have  access  to  a  console 
of  a  time-sharing  information  system.   As  such,  the  language  herein 
described  is  an  interactive  command  language  for  use  within  the  WEB 
system.   The  structure  of  WEB  change  orders  is  actually  quite  similar 
to  any  file  manipulation  system  in  which  files  can  be  created,  deleted, 
and  otherwise  revised.   As  such,  it  is  anticipated  that  file  manipu- 
lation routines  will  be  available  within  the  time-sharing  system, 
so  that  the  implementation  of  change  orders  should  only  require  an 
adaptation  of  existing  file  manipulation  routines. 

It  is  assumed  that  the  reader  is  familiar  with  "The  WEB 
System,  Part  II:   A  Formal  Description  of  the  WEB  Language." 

2.   BLOCK  DEFINITION  CHANGES 

DELETE-   If  a  defined  block  is  not  used  as  a  block  component,  this 
change  command  simply  deletes  the  definition  of  the  speci- 
fied block.   Otherwise,  a  BLOCK  NOT  DEFINED  message  is 
printed  for  each  occurence  of  this  block  as  a  block 
component  and  the  definition  is  deleted. 

EXCHANGE-  Exchanges  one  or  more  block  components  within  the  specified 
block  definition  for  new  block  components.   Any  revision 
more  complicated  than  this,  e.g.,  one  which  involves  the 
terminal  list  or  one  which  adds  more  blocks  than  it  deletes, 
or  vice  versa,  must  use  the  REVISE  command. 

REVISE-   The  definition  of  the  specified  block  is  first  deleted,  and 
then  the  new  definition  added.   All  current  usages  of  the 


block  are  automatically  updated  by  the  system,  with  the 
consequences  followed  through  to  wiring  changes.   Note 
that  the  usages  of  this  block  may  need  to  be  modified 
to  be  compatible  with  the  new  definition. 

ADD-      A  new  block  which  has  not  previously  been  used  is  defined. 

Unnamed  blocks  can  be  modified  in  the  same  manner  as 
named  blocks  by  referring  to  these  unnamed  blocks  as  NONAME  (n), 
as  discussed  in  The  WEB  System,  Part  IV.   Sub-blocks  deleted  from 
the  definition  of  a  block  will  not  cause  reassignment  of  index 
numbers  for  the  remaining  block  components  in  the  definition. 
Added  blocks  will  be  given  an  index  number  one  more  than  the  last 
remaining  block  in  the  definition. 

3.      BLOCK  COMPONENT   CHANGES 

The  consequences  of  all  the  following  changes  are  followed 
through  to  the  wiring  automatically. 

DELETE-   One  or  more  signal  names  are  deleted  from  the  terminal 
list  of  the  specified  block.   These  signal  names  may 
occur  anywhere  in  the  original  terminal  list.   Remaining 
names  are  then  collapsed  to  fill  the  spaces  left  by  the 
deletions.   This  command  should  only  be  used  to  make  the 
terminal  list  of  the  block  component  correspond  to  the 
terminal  list  in  the  definition  of  the  block  component. 

EXCHANGE-  One  or  more  names  in  the  terminal  list  of  the  block 
component  may  be  replaced  with  a  new  name. 

REVISE-   The  original  terminal  list  is  deleted  and  the  newly 
specified  terminal  list  is  added. 

ADD-      A  signal  name  or  names  is  added  to  the  end  of  the 
terminal  list  of  the  specified  block. 


h.      MODULE  DEFINITION  CHANGES 

DELETE-   This  command  deletes  a  module  definition  which  has  been 
completely  deleted  from  the  assignment  description. 

EXCHANGE-  One  or  more  units  of  the  specified  module  are  exchanged. 

REVISE-   Revises  a  module  definition,  having  the  effect  of  a 

delete  and  add.   Revisions  will  be  automatically  updated 
and  the  consequences  followed  through  to  the  wiring. 

ADD-      Adds  a  new  module  which  has  not  been  previously  used  in 
the  assignment  description. 

5-   MODULE  ASSIGNMENT  CHANGES 

The  consequences  of  all  the  following  changes  are  followed 
through  to  the  wiring  automatically. 

DELETE-   Deletes  a  module  from  an  old  location.   Logic  which  has 
been  placed  on  this  module  by  a  FILL  statement  must  be 
deleted  or  moved,  otherwise  a  MODULE  NOT  ASSIGNED  or  a 
NO  MATCH  message  will  be  printed  for  each  logic  unit  not 
deleted  or  moved,  unless  a  module  is  added  to  that  location, 
with  which  the  logic  FILL  statement  is  compatible. 

EXCHANGE-  Not  available. 

REVISE-   Changes  the  name  of  a  module  in  a  location.   The  old 

module  is  first  found  and  deleted.   Since  original  logic 
may  no  longer  match  the  new  module,  additional  statements 
might  be  necessary  to  update  the  desired  correspondence. 

ADD-      A  module  is  assigned  to  a  new  location. 

6.   UNIT  ASSIGNMENT  CHANGES 

The  consequences  of  all  the  following  changes  are  followed 
through  to  the  wiring  automatically. 


DELETE-   An  old  logic  unit  is  deleted  from  a  location. 

EXCHANGE-  Not  available. 

REVISE-    Same  effect  as  a  delete  and  add*   Used  to  move  a  logic 
unit  from  one  location  to  another. 

ADD-      Assigns  a  new  logic  unit  to  a  location. 

7.   WIRING  CHANGES 

For  purposes  of  wire  minimization,  files  will  be  processed 
in  one  of  two  modes:   The  PROTOTYPE  mode  is  the  normal  mode  for  WEB 
processing,  and  is  intended  to  correspond  to  an  unwired  assembly  which 
is  still  in  the  design  phase;  the  PRODUCTION  mode  is  to  be  used  when 
updating  a  file  for  an  assembly  which  has  already  been  wired,  and  is 
intended  for  debugging  changes,  etc. 

In  the  PRODUCTION  mode,  no  attempt  at  full  wire  minimization 
will  be  made,  rather  the  signal  path  will  be  made  to  correspond  to  the 
rest  of  the  file  with  the  fewest  number  of  wire  changes.  Minimization 
does  occur  under  these  constraints. 

i)   INTERCONNECT 

ADD-      The  wire  minimization  algorithm  is  constrained  to 

find  a  minimal  path  with  the  wires  herein  mentioned 
as  part  of  the  path.   The  points  listed  here  must 
be  points  which  actually  do  occur  in  the  signal 
path  as  defined. 

DELETE-   The  above  constraints  are  removed  from  the  wire 

minimization  algorithm.  The  path  is  automatically 
reminimized  according  to  any  remaining  constraints 
still  in  effect. 

EXCHANGE-  Not  available. 

REVISE-   Not  available. 


ii)  FORCE 

ADD-      This  statement  forces  a  wire  to  be  listed  between  the 

points  mentioned.   This  is  done  no  matter  what  the  con- 
sequences! 1   The  statement  should  be  used  only  in  des- 
peration.  As  no  indication  of  forced  wiring  is  explictly 
indicated  in  output  from  the  processor,  suitable  com- 
ments should  be  attached  with  this  statement. 

DELETE-   This  statement  forces  the  removal  of  the  indicated 
wires  from  a  signal  path. 

EXCHANGE-  Not  available. 

REVISE-   Not  available. 

Force  statements  must  be  specifically  deleted  if  at  some  later  date 
they  are  no  longer  necessary,  as  otherwise  they  will  remain  wired  as  ordered. 

8.   DISPLAY  COMMANDS 

An  important  part  of  any  interactive  system  is  the  displays  made 
available  to  the  user.   The  following  reports  are  proposed  as  necessary  for 
an  effective  system: 

a)  ASSIGNMENTS 

A  listing  (by  location)  of  modules  assigned,  with  unused  lo- 
cations flagged.  Also,  a  listing  (by  module)  of  locations  at  which  a 
particular  module  occurs.;  UNUSED  being  considered  a  module  type. 

b)  FILL 

A  listing  (by  location)  of  units  assigned  to  a  module,  with 
unused  locations  flagged.  Also,  a  listing  (by  units)  of  module  locations 
at  which  a  particular  unit  occurs.   UNUSED  is  considered  a  unit  type,  as 
above. 

c )  WIRING 

A  listing  (by  signal  path  or  by  connector)  of  wires  now  in 
the  file.    The  choice  of  format  is  to  be  suitable   for  wiring 


technician  and  logic  designer  (See  The  WEB  System,  Part  IV: 
Implementation) . 

d)  MODULE 

A  listing  of  module  definitions  now  available  in  the  file. 

e)  LOGIC 

A  statement  of  the  expanded  logic  now  in  the  file. 

f)  BLOCK 

A  listing  of  all  blocks  now  defined  in  the  file. 

g)  UNIT 

A  listing  of  all  units  now  defined  in  the  file. 

It  is  anticipated  that  the  foregoing  displays  would  have 
to  be  explicitly  requested.   The  following  reports  would  be  auto- 
matically provided: 

h)   ERROR  SIEVE 

A  list  of  items  in  the  file  which  are  in  error.   Appropriate 
comments  should  be  included. 

i)   TRANSACTIONS  REPORT 

A  listing  of  the  "first  level"  consequences  of  an  update, 
available  only  immediately  after  the  update  is  processed.   Errors 
are  flagged. 

j)   CHANGE  REPORT 

A  statement  of  all  changes  which  are  caused  by  an  update. 
These  changes  would  have  to  be  performed  on  an  existing  assembly 
to  make  the  physical  device  correspond  to  the  current  file.   Both 
previous  and  current  items  are  listed.   There  is  to  be  one  section 
for  each  type  of  change  command  (other  than  <  Display  Command>)  . 
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9 •   ERRORS 

Since  this  system  is  to  be  primarily  used  to  remove  design 
errors  from  an  assembly  before  it  is  wired,  it  is  hoped  that  the 
user  will  not  be  bogged  down  with  the  mechanics  of  using  the  system. 
Certainly,  however,  errors  in  the  usage  of  the  change  orders  will 
occur.   To  this  end,  error  messages  should  be  liberally  generated  to 
guide  the  user  in  the  correct  utilization  of  the  system.   Accordingly, 
the  following  list  is  intended  as  a  partial  list  of  possible  errors 
in  file  manipulation  and  usage  of  the  system: 

NOT  IN  FILE  -  for  a  REVISE,  DELETE,  or  EXCHANGE  statement 
which  refers  to  something  not  in  the  file. 

ALREADY  IN  FILE  -  for  an  ADD  statement  which  refers  to 
something  already  in  the  file. 

FORMAT  CHECK  -  for  a  statement  which  uses  improper  or 
unintelligible  format. 

DUPLICATE  CHANGE  -  for  two  statements  in  the  same  update 
which  refer  to  identical  items.   Some  conflicts  of 
this  sort  may  be  resolved  by  the  order  of  execution, 
which  should  be:   DELETE,  REVISE,  EXCHANGE,  ADD. 

Priority  levels  of  information  are: 

BLOCK  DEFINITION  *-  BLOCK  COMPONENT  . 


FILL 
MODULE  DEFINITION ^  ASSIGN ^ 

Violation  of  priority  leads  to  such  errors  as: 

BLOCK  NOT  DEFINED  -  block  was  called  but  not  defined. 

MODULE  NOT  DEFINED  -  module  was  assigned  but  not  defined. 

MODULE  NOT  ASSIGNED  -  a  fill  statement  was  given  for  a 
location  to  which  no  module  was  assigned. 

NO  SUCH  INDEX  -  a  fill  statement  was  given  for  a  logic  unit 
with  a  non-existent  index  number. 
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In  addition  conflicts  can  arise  such  as: 

NO  MATCH  -  logic  unit  does  not  match  module  unit. 

NO  CIRCUIT  -  logic  unit  was  assigned  by  a  fill  statement 
to  a  module  which  does  not  contain  a  unit  position 
as  designated  in  the  fill  statement. 

TERMINAL  CHECK  -  signal  list  of  component  block  does  not 
correspond  in  length  to  terminal  list  in  definition 
of  block. 

DUPLICATE  ASSIGN  -  two  modules  assigned  to  the  same 
location. 

DUPLICATE  FILL  -  two  logic  units  assigned  to  the  same 
unit  of  a  module . 

ILLEGAL  LOCATION  -  cell  or  pin  number  is  illegal. 

DUPLICATE  PIN  -  two  pin  numbers  of  a  module  definition 
are  the  same . 

In  cases  of  DUPLICATE  ASSIGN  or  FILL,  the  earliest  chrono- 
logical statement  is  executed,  the  latter  one  or  more  statements  are 
ignored.   In  the  case  of  any  other  error  mentioned  so  far  the  er- 
roneous statement  is  ignored.   Note  that  ignored  statements  if 
desired  must  be  resubmitted  after  suitable  modification  to  the 
file. 

Other  errors  resulting  from  Wiring  Changes  are: 

PATH  DISCONNECT  -  a  signal  path  has  been  broken  into  two 
or  more  unconnected  pieces. 

LOOP  -  a  signal  path  contains  a  loop  (or  cycle). 

TOO  MANY'  CONNECTIONS  -  three  or  more  wires  have  been 
connected  to  the  same  point. 

These  statements  in  supposed  error  will  be  executed  but 
noted,  if  as  a  result  of  a  FORCE  statement.   If  as  the  result  of  an 
INTERCONNECT  statement,  however,  the  statement  in  error  is  ignored. 
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10.   SYNTAX  FOR  WEB  CHANGE  ORDERS 

Syntactic  variables  not  defined  within  this  section  are 
to  be  found  in  section  6  of  "The  WEB  System,  Part  II:   A  Formal 
Description  of  the  WEB  Language."   Notation  introduced  there  is  used 
here , 

<WEB  f  ile>  <-  <File  name>  :  (  <File  mode>  )  ;   <WEB  input> 

<File  name>  <-  <Identif ier> 

<File  mode>  *-   PROTOTYPE  |  PRODUCTION 
<Change  program>  <-  WEB    UPDATE  ;   _  <Change  order>  _    END     UPDATE  ; 


<Change  order>  «-  OPEN  <File  name>  ;  CHANGE 

_  <Change  command>  _    CLOSE   [  <File  name>  ]  ; 

<Change  command>  *-  <Logic  change>  |  <Module  definition  change> 

I  <Assignment  change>  [  <Wiring  change> 
|  <Display  command> 

<Logic  change>  *-   <Block  definition  change>  |  <Block  component 
change> 

<Block  definition  change>  +-   BLOCK    DEFN  ;  <Block 

definition  type> 

<Block  definition  type>  <-  DELETE   <Block  name>  ; 

|  EXCHANGE   <Block  name>  : 
<Block  component>  - 
<Block  component> 
|  REVISE   <Block  definition> 
|  ADD   <Block  definition> 
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<Block  component  change>  <-  BLOCK     CCMP  ;  <Block 

specification>  ;  <Component 
type> 

<Block  specification>  <-  <Block  name>  |  <Index  number 

expression> 

<Component  type>  -  DELETE   <Terminal  list>  ; 

|  EXCHANGE   J|_  <Signal  element>  = 

<Signal  element>  j 
|  REVISE   <Terminal  list>  ; 
|  ADD   <Terminal  list>  ; 

<Module  definition  change>  «-  MODULE     DEFN  ;   <Module 

definition  type> 

<Module  definition  type>  «-  DELETE   <Module  name>  ; 

|  EXCHANGE   JJ_  Module  component> 

<Module  component>  ; 
|  REVISE   <Module  de script ion> 
|  ADD   <Module  description> 

<Assignment  change>  «-  <Module  assignment  change> 

|  <Unit  assignment  change> 

<Module  assignment  change>  <-  MODULE     ASSIGN  J  <Change 

type>   <Assign  component> 

<Change  type>  *-   DELETE  |  REVISE  [  ADD 

<Unit  assignment  change>  <-   UNIT     ASSIGN  J  <Qnit 

assignment  type> 
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<Unit  assignment  type>  *-  DELETE   <Index  number 

expression>  ; 

|  REVISE   <Fill  component> 
|  ADD   <Fill  component> 

<Wiring  change>  «-  WIRING  ;  {  INTERCONNECT  |  FORCE  }  ; 

<Wiring  type> 

<Wiring  type>  «-  {  DELETE  |  ADD  }   <Index  number  expression> 
<Signal  name  expression>  : 

<Array  nomenclature  expression>  = 
<Array  nomenclature  expression>  ; 
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